Software Reuse in Safety-Critical Systems

ion is one of the fundamental ways that complexity is addressed in software development. “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer" [22]. Encapsulation is the process of hiding the design details in the object implementation. Encapsulation can be described as “the mechanism that binds together code and the data it manipulates, and keeps both safe from outside interference and misuse” [23]. Encapsulation is generally achieved through information hiding, which is the process of hiding the aspects of an object that are not essential for the user to see. Typically, both the structure and the implementation methods of the object are hidden [22]. Modularity is the process of partitioning a program into logically separated and defined components that possess defined interactions and limited access to data. Booch writes that modularity is a “property of a system that has been decomposed into a set of cohesive and loosely coupled modules” [22]. Hierarchy is simply the ordering of abstractions. Examples of hierarchy are single inheritance and multiple inheritance. In OOT, when a sub-class is created, this new class “inherits” all of the existing attributes and operations of the original class, called the “parent” or “superclass” [24]. Inheritance is a relationship between classes where one class is the “parent” (also called “base,” “superclass,” or “ancestor”) class of another [25]. One author puts it this way, “Inheritance is a relationship among classes where a child class can share the structure and operations of a parent class and adapt it for its own use” [26]. Inheritance is one of the key differences between OOT and conventional software development. There are two types of inheritance: single inheritance and multiple inheritance. In single inheritance, the sub-class inherits the attributes and operations from a single superclass. In multiple inheritance, the sub-class inherits some attributes from one class and others from another class. Multiple inheritance is controversial, because it complicates the class hierarchy and configuration control [27]. Typing is a principle that is used in OOT that has many definitions. Booch presents one of the most clear and concise definitions by stating, “Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways” [22]. Examples of OOT typing are strong typing, weak typing, static typing, and dynamic typing. Each OOT programming language varies in its implementation of typing. Another OOT concept closely related to typing is polymorphism. Polymorphism comes from the Greek meaning “many forms.” It allows one name to be used for two or more related but different purposes [23]. It is the ability of an object to assume or become many different forms of object. Polymorphism specifies slightly different or additional structure or behavior for an object, when assuming or becoming an object [25]. This allows different underlying implementations for the same command. For example, assume there exists a vehicle class that includes a steer-left command. If a boat object was created from the vehicle class, the steer-left Leanna Rierson 23 May 1, 2000 command would be implemented by a push to the right on a tiller. However, if a car object was created from the same class, it might use a counter-clockwise rotation to achieve the same command. Concurrency is the process of carrying out several events simultaneously. Persistence is “the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s locations moves from the address space in which it was created)” [22]. 6.1.2 OOT Methodology Everyone seems to have a slightly different perspective of what OOT actually entails. OOT can be described in four phases: Object-Oriented Analysis (OOA), Object-Oriented Design (OOD), Object-Oriented Programming (OOP), and Object-Oriented Verification/Test (OOV/T). The implementation of these phases is typically iterative or evolutionary. An overview of each phase will be addressed below. 6.1.2.1 OOA is the process of defining all classes that are relevant to solve the problem and the relationships and behavior associated with them [27]. A number of tasks occur to carry out the OOA as shown in Figure 4. The tasks are reapplied until the model is completed. As shown in Figure 4, use cases, class-responsibility-collaborator (CRC) models, object-relationship (OR) models, and object-behavior (OB) models are methods typically used to carry out the OOA. The use case is a method utilized to identify the user’s requirements. The CRC model is used to identify the class attributes, operations, and hierarchy. The OR model is used to illustrate the relationship between the numerous objects. And, the OB model is used to model the behavior of each object. 6.1.2.2 OOD transforms the OOA into a blueprint for software construction. Four layers of design are usually defined: subsystem layer, class and object layer, message layer, and responsibilities layer. The subsystem design layer represents each subsystem that enables software to achieve the requirements. The class and object design layer contains class hierarchies and object designs. The message design layer contains the internal and external interfaces to communicate between objects. The responsibilities design layer contains the algorithm design and data structures for attributes and operations of each object. The Unified Modeling Language (UML) is becoming the standard technique for graphical design of embedded systems [28]. The UML provides a way of smoothly transitioning from OOA to OOD. 6.1.2.3 OOP is the coding phase of the design project, using an object-oriented (OO) language. There are dozens of OO languages. Three of the most well known are C++, Smalltalk, and Java. C++ and Java are of particular interest for designers of embedded software. Java’s platform independence and C++’s tool support make these two languages very appealing to the developers of safety-critical systems. Because of their extreme popularity and the desire for use in safety-critical systems, both C++ and Java will be discussed in sections 6.3 and 6.4, respectively. Leanna Rierson 24 May 1, 2000 Identify user requirements (use cases) Identify classes (attributes & operations) (CRC) Specify class hierarchy (CRC) Identify objectto-object relationships (OR) Model object behavior (OB) R e aply as neded Figure 4 – OOA Tasks 6.1.2.4 OOV/T is the process of detecting errors and verifying correctness of the OOA, OOD, and OOP. OOV/T includes reviews, analyses, and tests of the software design and implementation. OOV/T requires slightly different strategies and tactics than the traditional structured approach. The variance in the approach is driven by characteristics like inheritance, encapsulation, and polymorphism. Most developers use a “design for testability” approach to begin addressing any verification and test issues early in the program. 6.2 Overview of C++ To date C++ has been used in only a few safety-critical systems. However, many developers are seriously considering the use of C++ in future developments. This section will provide an overview of C++, with emphasis on embedded systems, since most safety-critical systems fall into this category. C++ is an object-oriented language that has many similarities to C. In fact C++ is a superset of C. Typically, C and C++ can run on the C++ compiler. Because of the fact that embedded systems are becoming larger and more complex, the tool support and objectorientation support of C++ are appealing [29]. C has gained quite a bit of popularity in the embedded software community; however, the limited tool support and difficult maintenance issues surrounding C are leading many to start looking at other options. A paper by Dan Saks entitled “How to Evaluate C++ as a Language for Embedded Programming” lists the following advantages of C++ over C [29]: • “C++ is a better C.” C++ is a superset of C. C++ applies stricter translation-time checking than C does; consequently, C++ compilers detect more errors. • “C++ supports data abstraction.” C++ supports objects and classes, which makes for easier program maintenance. Leanna Rierson 25 May 1, 2000 • “C++ supports object-oriented programming.” OOA and OOD are easy to implement in C++. • “C++ partitions the name space better than C.” This reduces the chance of global naming conflicts. Saks also lists that a couple of disadvantages of C++ are its complexity and its hidden run-time burdens [29]. He states that C++ “compiler diagnostics can be very cryptic. Run-time bugs can be very subtle. C++ places higher demands on tools such as linkers and debuggers” [29]. Overall, C++ typically increases execution time and data and code space [30].